PR1 Service Portfolio Management (SPM)

PR1.1 Ein Serviceportfolio muss gepflegt werden. Alle Services müssen als Teil des Serviceportfolios spezifiziert werden.

• (studiengangspezifisches) Modulhandbuch
• KVV
• u.A.

PR1.2 Design und Transition neuer oder geänderter Services müssen geplant werden.

• hier: Aufgabe des Projektmanagements des Einführungsprojekts KVV

PR1.3 Pläne für das Design und die Transition neuer oder geänderter Services müssen den zeitlichen Rahmen, Verantwortlichkeiten, neue oder geänderte Technologie, Kommunikation und Service-Abnahmekriterien berücksichtigen.

PR1.4 Die organisatorische Struktur, die der Service-Erbringung zugrunde liegt, muss identifiziert werden, einschließlich einer möglichen Föderationsstruktur sowie Kontaktpunkte und Ansprechpartner für alle involvierten Parteien.

• Organigram für alle beteiligten Personen?
• Welche Menschen sind beteiligt?
• Welche Rollen (Dekan, Studiendekan, Fakultätsassistent etc.) sind beteiligt?
• Welche Rollen brauchen wir für die Beschreibung der Prozeduren und Funktionen?

PR2 Service Level Management (SLM)

PR2.1 Ein Servicekatalog muss gepflegt werden.

• Ziel: online, siehe Services

PR2.2 Zu allen Services, die für Kunden erbracht werden, müssen Service Level Agreements (SLAs) bestehen.

• Wahl(pflicht)fächer im KVV Eintrag sofort nach Beschluss im Fakultätsrat Wahl(pflicht)fächer sind vollsändig enthalten
• Studienprojekte vollständig spätestens 2 Wochen vor Wahl darf auch gerne schon Monate vorher sein auch studentisch initiierte Projekte mit aufnehmen? / Datenschutz
• Instanzen von Seminaren (z.B. WIF640) vollständig spätestens 2 Wochen vor Wahl bei Lehrbeauftragten zusätzlich auch Vita

PR2.3 SLAs müssen in geplanten Abständen überprüft werden.

• JB: Es muss nicht das Einhalten der SLA überprüft werden, sondern ob sie als Maßstab angemessen sind.
• findet im Fakultätsrat statt

PR2.4 Die Leistung der Services muss gegen die in den SLAs festgelegten Service-Ziele bewertet werden.

• Zykluszeit: einmal pro Semester
• Welche Leistungsindikatoren werden angesetzt? JB: sind in den SLA beschrieben
• Wer führt die Bewertung durch? JB: Studiendekan? JB: könnten das auch die Kunden sein?

PR2.5 Um das Erreichen der in den SLAs festgelegten Service-Ziele sicherzustellen, müssen in geeignetem Umfang Operational Level Agreements (OLAs) und Underpinning Agreements (UAs) für unterstützende Services oder Servicekomponenten vereinbart werden.

• Welche Zulieferer sind Intern (OLA)? ---- Rechenzentrum? ... alternativ Sekretäriat? JB: RZ für die Wiki-Engine, aber nicht für das KVV
• Welche Zulieferer sind extern (UA)? --- Dozenten? JB: OLA mit anderen Dozenten; UA mit Lehrbeauftragten

PR2.6 OLAs und UAs müssen in geplanten Abständen überprüft werden.

• Welche Stelle führt die Überprüfung/Bewertung durch?
• Welche Kriterien werden hier angesetzt?
• JB: Es muss nicht das Einhalten der SLA überprüft werden, sondern ob die OLA und UA als Maßstab angemessen sind.

PR2.7 Die Leistung von Servicekomponenten muss gegen die in den OLAs und UAs festgelegten operativen Zielwerte bewertet werden.

• Welche Leistungsindikatoren werden angesetzt? A: OLA, UA
• Wer führt die Bewertung durch? JB: Studiendekan im Rahmen des SRM JB: könnten das auch die Kunden sein?

PR3 Service Reporting Management (SRM)

PR3.1 Service-Berichte müssen spezifiziert und mit ihren Empfängern abgestimmt werden.

• Welche Eigenschaften des KVV müssen Reportet werden ---- Einhaltung der Ziele, Zugriffszahlen, Informationsvollstängikeit? JB: m.E jedenfalls Vollständigkeit und Aktualität, als Indikatoren für Brauchbarkeit

PR3.2 Die Spezifikation eines jeden Service-Berichts muss eine eindeutige Bezeichnung des Berichts, seinen Zweck, seinen Empfängerkreis, seine Frequenz, seine Inhalte, sein Format sowie die Methode der Bereitstellung des Berichts umfassen.

• Bezeichnung und Zweck festlegen
• Empfängerkreis definieren JB: Fakultätsrat im Rahmen des sog. "Lehrberichts"
• Welche Frequenz ist sinnvoll --- ein Semester oder mehr?
• Template Vorgaben --- Corporate Identity?
• Teilweise? Automatisch erstellbar? --- Wenn nicht wer erstellt den Bericht?

PR3.3 Service-Berichte müssen gemäß den Spezifikationen erstellt werden. Das Service-Berichtswesen muss Leistung im Vergleich mit vereinbarten Zielen, Informationen über signifikante Ereignisse und ermittelte Fälle von Nichtkonformität darstellen.

PR4 Service Availability & Continuity Management (SACM)

PR4.1 Verfügbarkeits- und Kontinuitätsanforderungen im Zusammenhang mit Services müssen unter Berücksichtigung von SLAs identifiziert werden.

• Verfügbarkeit des Servers: 24/7
• Aktualität der Daten Wahl(pflicht)fächer: idealerweise sofort nach Beschluss im FakRat, allerspätestens 5 Werktage vor der Wahl im SB-Portal

PR4.2 Service-Verfügbarkeits- und Kontinuitätspläne müssen erstellt und gepflegt werden.

PR4.3 Die Planung der Service-Verfügbarkeit und -Kontinuität muss Maßnahmen zur Reduzierung von Eintrittswahrscheinlichkeit und Auswirkung identifizierter Verfügbarkeits- und Kontinuitäts-Risiken berücksichtigen.

• Risikoanalyse erforderlich: Was ist ein Risiko in Bezug auf das KVV? OLA, ULA werden nicht eingehalten, d.h. Dozenten liefern nicht rechtzeitig eine Beschreibung Beschreibung wechselt häufig oder ist unklar

PR4.4 Die Verfügbarkeit von Services und Servicekomponenten muss überwacht werden.

• Welche Komponenten/Eigenschaften müssen überwacht werden, um Verfügbarkeit garantieren zu können?

PR5 Capacity Management (CAPM)

PR5.1 Kapazitäts- und Leistungsanforderungen im Zusammenhang mit Services müssen unter Berücksichtigung von SLAs identifiziert werden.

• Kapazität in Abhängigkeit von Anzahl der Studenten, Dozenten und weiteren Benutzern
• JB: klären, wie viel Aufwand die Pflege des

PR5.2 Kapazitätspläne müssen erstellt und gepflegt werden.

• - Wer erstellt/pflegt Pläne?

PR5.3 Die Kapazitätsplanung muss personelle, technische und finanzielle Ressourcen berücksichtigen.

• In welchem Zeitraum werden die Ressourcenpläne aktualisiert?

PR5.4 Die Leistung von Services und Servicekomponenten muss auf Basis von Auslastung und identifizierten operativen Warnungen und Ausnahmen überwacht werden.

PR6 Information Security Management (ISM)

PR6.1 Informationssicherheits-Richtlinien müssen definiert werden.

• - personenbezogene Daten besonders schützen
• JB: kennt die jemand genauer? ja; z.B. auch Schutz gegen unbeabsichtigte Fake-Inhalte?

PR6.2 Physische, technische und organisatorische Informationssicherheits-Maßnahmen müssen umgesetzt werden, um die Eintrittswahrscheinlichkeit und Auswirkung identifizierter Informationssicherheits-Risiken zu reduzieren.

• - Verschlüsselung aller Daten
• - sicherer Übertragungsweg

PR6.3 Informationssicherheits-Richtlinien und –Maßnahmen müssen in geplanten Abständen überprüft werden.

PR6.4 Informationssicherheits-Ereignisse und -Vorfälle müssen angemessen priorisiert und entsprechend behandelt werden.

PR6.5 Zugangs- und Zugriffskontrolle für informationsverarbeitende Systeme und Services, einschließlich der Vergabe von Zugriffsrechten, muss auf konsistente Art und Weise durchgeführt werden.

PR8 Supplier Relationship Management (SUPPM)

PR8.1 Zulieferer müssen identifiziert werden

• Dozenten und Lehrbeauftragt mit deren Vita und weiterführenden Informationen
• Gastredner aus Firmen oder anderen Institutionen (Kooperationen mit der Hochschule)

PR8.2 Für jeden Zulieferer muss eine designierte Kontaktstelle oder -person festgelegt werden, die das Management der Beziehung mit dem Zulieferer verantwortet.

• Lehrbeauftragte: Studiengangleiter
• Dozenten aus dem Haus: Modulverantwortliche und/oder Studiengangleiter
• Dekanat

PR8.3 Mechanismen zur Kommunikation mit Zulieferern müssen etabliert werden.

• Ggf. eine Moodle-Gruppe für alle Dozenten eines Semesters? Eine Seite im KVV selbst?
• E-Mail und Telefon
• Skypedienste anbieten (Chat)
• Lokalisierung von Dozenten auf dem Campus

PR8.4 Die Leistung der Zulieferer muss überwacht werden.

• JB: "Leistung" hier nicht zu verstehen in Bezug auf Servicebereich 1 LLV Analyse und Bewertung der Evaluierung durch bspw. des Dekanats oder einer anderen Organisation Dokumentation der Evaluierung

PR7 Customer Relationship Management (CRM)

PR7.1 Die Kunden der Services müssen identifiziert werden.

• Studenten und Studentinnen
• evtl. Studieninteressierte
• andere Dozenten JB: ja, das ist interessant: andere Dozenten sind ja vor allem Zulieferer; Chance des KVV: auch Dozenten als Kunden interpretieren, damit die ihre eigene Lehre besser aufeinander abstimmen können? auch Terminplanung auch Leistungsanforderungen und -Nachweise

PR7.2 Für jeden Kunden muss eine designierte Kontaktstelle oder -person festgelegt werden, die das Management der Kundenbeziehung und -zufriedenheit verantwortet.

• Studierenden-Service-Zentrum im Studierendenhaus JB: auch in Bezug auf das KVV?
• Dekanat - für die Dozenten
• JB: KVV-Helpdesk (Funktion)

PR7.3 Mechanismen zur Kommunikation mit Kunden müssen etabliert werden.

• Email
• Q&A JB: auch im Wiki!
• Direkter Kontakt zu Sprechstundenterminen
• Skype-einbindung ... JB: Bitte nicht ;-)
• FAQ
• integriertes Chatsystem

PR7.4 Service-Reviews unter Einbeziehung der Kunden müssen in geplanten Abständen durchgeführt werden.

• Evaluationen am Ende jeden Semesters Eval durch die Kunden ja - aber bzgl. KVV am *Ende* des Semsters? Oder z.B. auch in der Woche, in der die Wahl der FWPF durchgeführt wird?
• Umfragen im KVV ... JB: z.B. auch "gefätt mir"? (aber hier ist die Aussagekraft unklar)
• Evaluierung auch bei Servicemitarbeitern (ggf. Veröffentlichung auf der Personalisierung der HP)

PR7.5 Kundenbeschwerden im Zusammenhang mit Services müssen auf konsistente Art und Weise erfasst und behandelt werden.

• Ticketsystem JB: hier sind auch SLA relevant: Antwortzeiten auf ein Ticket vereinbaren?
• Telefonhotline (24h) :-P JB: unser Sekretariat-AB hat 24h Dienst ;-)

PR7.6 Kundenzufriedenheit muss gemanagt werden.

• Aufgrund der in PR7.4 durchgeführten Evalutionen und Umfragen Changes durchführen
• (Internes oder externes) Organ muss festgelegt werden, der alle Kundenbeschwerden analysiert und bewertet (bspw. für jedes Quartal)

PR9 Incident & Service Request Management (ISRM)

PR9.1 Alle Incidents und Service-Requests müssen auf konsistente Art und Weise erfasst, klassifiziert und priorisiert werden.

• Grobe spezifikation was als Servicerequest was als Incident einzuordnen ist
• Welche Incidents können auftreten? --- Tabelle -> Tabelle sollte laufend angepasst werden
• Wie werden Incidents / Service Requests erfasst? Tool?
• JB: "Incident" Ein Leistungsversprechen wird nicht eingehalten. Mir aber unklar: Was könnte ein SR sein?

PR9.2 Die Priorisierung von Incidents und Service-Requests muss die in den SLAs festgelegten Service-Ziele berücksichtigen.

• Nach welchem Modell wir die Priorisierung durchgeführt. --- Evtl. Scroing-Modell, Risikomatirx

PR9.3 Die Eskalation von Incidents und Service-Requests muss auf konsistente Art und Weise erfolgen.

• Definition der Eskalationsebenen --- RACI?

PR9.4 Der Abschluss von Incidents und Service-Requests muss auf konsistente Art und Weise erfolgen.

• Definition wann ist ein Incident "abgeschlossen"? --- Limit an Bearbeitungsstunden etc?

PR9.5 Personen, die in den Prozess Incident & Service Request Management eingebunden sind, müssen Zugang zu relevanten Informationen wie bekannten Fehlern und Workarounds sowie zu Konfigurations- und Release-Informationen erhalten.

• Eigene Knowledge Datenbank? ...
• JB: ggf. das Wiki selbst?

PR9.6 Anwender müssen über den Fortschritt der von ihnen gemeldeten Incidents und ausgelösten Service-Requests auf dem Laufenden gehalten werden.

• Ticketsystem?

PR9.7 Es müssen klare Festlegungen zur Ermittlung von Major Incidents sowie zum konsistenten Umgang mit ihnen existieren.

• Definition von "Major" .... evtl Potzenzielle Schadenshöhe? ja, unnbedingt. Z.B. und insbesondere: Eine wählbare V ist nicht im KVV enthalten; Festlegen von Kriterien die eine Eskalation auslösen

PR10 Problem Management (PM)

PR10.1 Probleme müssen mittels Trendanalysen auf der Basis von Incidents identifiziert und registriert werden.

• ggf. Tickets analysieren und ähnliche Tickets zusammenfassen
• Problemkategorieen anlegen

PR10.2 Probleme müssen untersucht werden, um Maßnahmen zu ihrer Beseitigung oder zur Reduzierung ihrer Auswirkungen auf Services zu identifizieren.

PR10.3 Wenn ein Problem nicht dauerhaft beseitigt wird, muss das Problem als bekannter Fehler erfasst werden, zusammen mit Maßnahmen wie effektiven Workarounds oder Umgehungslösungen.

PR10.4 Aktuelle Informationen über bekannte Fehler und effektive Workarounds müssen gepflegt werden.

PR11 Configuration Management (CONFM)

PR11.1 Typen von Configuration Items (CI) und Beziehungen müssen definiert werden.

• Berechtigungen der User? --- Wer darf welche Informationen aktualisieren? JB: und sehen?!
• Formulare für Datenerfassung?
• Vorlagen für Dokumentation?

PR11.2 Der Detailgrad der aufgezeichneten Konfigurationsinformationen muss ausreichend sein, um eine effektive Kontrolle über die CIs zu unterstützen.

• Definition von "ausreichend" und "effektiv"

PR11.3 Jedes CI und seine Beziehungen mit anderen CIs müssen in einer Configuration Management Database (CMDB) aufgezeichnet werden.

• Mindmap oder ER?

PR11.4 CIs müssen gesteuert und überwacht und Änderungen an CIs in der CMDB nachverfolgt werden.

• Ab welcher "größe" von Änderung müssen diese erfasst werden ... wer führt diese Änderungen durch und wie werden Sie gemeldet?

PR11.5 Die in der CMDB gespeicherten Informationen müssen in geplanten Abständen verifiziert werden.

• Wie lang sind diese Abstände? -- 1 Semester?
• Wie wird die verifizierung Durchgeführt?

PR11.6 Vor einem neuen Release in die Produktivumgebung muss eine Configuration Baseline der betroffen CIs erstellt werden.

• RACI um A I etc. festzulegen
• Wie findet die Erstellung der Baseline statt

PR12 Change Management (CHM)

PR12.1 Alle Changes müssen auf konsistente Art und Weise erfasst und klassifiziert werden.

• - Wie werden diese erfasst? Z. B. mit einem Tool, etc.

PR12.2 Alle Changes müssen auf konsistente Art und Weise beurteilt und genehmigt werden.

• Welche Kriterien dienen für die Beurteilung?
• RACI für Genehmigung?

PR12.3 Alle Changes müssen auf konsistente Art und Weise einem Post Implementation Review unterzogen und abgeschlossen werden.

• Kriterien aus PR12.2 übernehmen --- Wer führt die Bewertung druch? Welche Parteien nehmen am Review teil?

PR12.4 Es müssen klare Festlegungen zur Ermittlung von Notfall-Changes sowie zum konsistenten Umgang mit ihnen existieren.

• Festlegen was Notfall-Changes sind und erstellen einen klaren Handlungsanweisung
• Eigenen BPMN-Prozess dazu definieren

PR12.5 Bei der Entscheidung über die Genehmigung von Requests for Changes müssen Nutzen, Risiken, potenzielle Auswirkungen auf Services und Kunden sowie die technische Realisierbarkeit berücksichtigt werden.

• Gremium für diese Bewertung definieren.
• Bewertungskriterien teilweise vorgeben?

PR12 Change Management (CHM) (Forts.)

PR12.6 Ein Zeitplan der Changes muss gepflegt werden. Er muss Angaben zu genehmigten Changes und vorgesehenen Terminen für die Produktivsetzung enthalten, welche an relevante Parteien kommuniziert werden können.

• Wie wird die Dokumentation realisiert ... Vorzugsweise Softwareunterstützt ... ähnlich Github für Softwareentwicklung

PR12.7 Für Changes von mit hoher Auswirkung oder hohem Risiko müssen die Schritte geplant und getestet werden, die notwendig sind, um den Change im Falle einer fehlgeschlagenen Produktivsetzung wieder rückgängig machen zu können oder eingetretene negative Effekte beheben zu können.

• Archivierung eines Backupsystems am Tag der Umstellung?

PR13 Release & Deployment Management (RDM)

JB: Was ist im Fall des KVV ein Release? ... wenn es ein pdf-Dokument wäre eine bestimmte Ausgabe; aber in einem Wiki?

PR13.1 Eine Release-Richtlinie muss definiert werden.

PR13.2 Die Produktivsetzung neuer oder geänderter Services und Servicekomponenten muss unter Einbeziehung aller relevanter Parteien, einschließlich betroffener Kunden, geplant werden.

• - alle Parteien rechtzeitig über Release informieren

PR13.3 Releases müssen vor dem der Produktivsetzung zusammengestellt und getestet werden.

PR13.4 Abnahmekriterien für jedes Release müssen mit Kunden und anderen relevanten Parteien abgestimmt werden. Die Einhaltung der Abnahmekriterien muss verifiziert werden, bevor das Release für die Produktivsetzung freigegeben wird.

• - Wie werden Abhnahmekriterien mit Kunden / anderen Parteien abgestimmt? Wie oft werden diese abgestimmt? nur einmalig?

PR13.5 Die Vorbereitung für die Produktivsetzung muss Schritte beinhalten, die im Falle des Fehlschlagens der Produktivsetzung unternommen werden, um Auswirkungen auf Services und Kunden zu reduzieren.

• - Alternativen schaffen; z.B. Moodle nutzen oder eigene Websites für Professoren, Dozenten, Lehrbeauftragte,...
• - Weitere Alternative bessere Ausarbeitung des Modulhandbuchs bzw. Vorlesungsverzeichnisses
• - Homepage der FH mit mehr Informationen ausstatten
• - möglichen Rollback auf altes Release vorbereiten und Rollback-Mechanismus testen

PR13.6 Releases müssen auf Erfolg oder Fehlschlagen überprüft werden.

• Nach welchen Kriterien wird Erfolg bzw. Fehlschlag gemessen?

PR14 Continual Service Improvement Management (CSI)

PR14.1 Verbesserungspotenziale müssen auf konsistente Art und Weise identifiziert und erfasst werden.

• Wie werden diese erfasst? Z. B. mit einem Tool, etc.

PR14.2 Verbesserungspotenziale müssen auf konsistente Art und Weise bewertet und genehmigt werden.

• RACI Matrix zum Festlegen der Accountability